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Abstract 

The  X  Window  System  has  come  to  be  accepted 
as  the  standard  for  developing  graphical  user 
interfaces  on  mid  to  high  range  workstations. 
Ada  interfaces  to  X  through  the  use  of  bindings 
were  developed  in  the  late  1980*6  under  the  Soft¬ 
ware  Tfechnology  for  Adaptable  Reliable  Systems 
(STARS)  contracts.  The  bindings  have  not  been 
maintained,  and  as  they  become  more  obsolete, 
many  are  converting  their  applications  to  newer 
sets  of  commercially  available  bindings.  This  pa¬ 
per  discusses  how  the  bindings  work  and  two 
strategies  for  converting  out  of  the  STARS  bind¬ 
ings. 

1  Introduction 

The  X  Window  System  was  developed  by  the 
Massachusetts  Institute  of  Technology  (MIT)  in 
partnership  with  Digital  Equipment  Corporation 
(DEC).  Released  in  1986,  it  supplies  a  flexible, 
object-oriented,  graphic  toolkit  that  can  be  used  to 
develop  user  interfaces.  Now  in  the  fifth  release 
of  its  second  major  version  (X11R5),  X  has  become 
the  de-facto  standard  interface  with  workstation 
manufacturers  [5]. 

Ada  bindings  to  X  were  developed  in  the  late 
1980’s  under  the  Software  Technology  for  Adapt¬ 
able  Reliable  Systems  (STARS)  contracts.  The 
bindings  do  not  cover  the  full  X  specification,  have 
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various  execution  problems,  and  are  not  main¬ 
tained  131.  As  new  versions  of  the  X  Window  Sys¬ 
tem  are  released,  the  STARS  bindings  become  in¬ 
creasingly  obsolete. 

This  paper  discusses  strategies  for  converting 
from  these  old  bindings  to  the  newer  bindings  that 
are  being  commercially  supported  An  overview 
of  the  X  Window  System  is  given  along  with  a  dis¬ 
cussion  of  how  Ada  binds  to  X.  Examples  are  pre¬ 
sented  that  demonstrate  how  the  strategies  for 
conversion  have  been  used  to  convert  Saber  (an 
air/land  battle  wargame)  from  STARS  to  bindings 
developed  by  Software  Engineering  Research  Cor¬ 
poration  (SERC). 

2  The  X  Window  System:  A  Brief 
Overview 

The  X  Window  System  uses  a  client-server  ar¬ 
chitecture  that  is  designed  to  take  advantage  of 
networked  systems.  A  server  process  runs  on 
each  display  machine  in  a  network  (see  Figure 
1),  it  functions  as  the  interface  to  that  device's 
hardware.  Client  applications  communicate  with 
the  server  to  have  it  display  images  and  react 
when  the  user  takes  specific  actions.  Clients  and 
servers  may  run  on  the  same  or  different  ma¬ 
chines. 

An  X  client  application  may  utilize  several  lay¬ 
ers  of  software,  as  shown  in  Figure  2.  Each  layer 
is  an  independent  set  of  library  calls,  with  each 
higher  level  having  complete  access  to  any  of  the 
lower  layers. 


2.1  X  Library 


Figure  1 ;  Client-Server  Architecture  of  the  X  Win¬ 
dow  System 


'The  lowest-level  functionality  of  the  X  Window 
System  is  the  X  Library  (Xlib).  This  library 
provides  the  very  bae.:  functions  needed  to  ren¬ 
der  images  on  a  display.  Examples  would  be 
drawing  lines,  defining  display  colors,  handling 
keystrokes,  etc 

2.2  X  Toolkit  intrinsic^ 

Programming  in  Xlib  can  be  a  very  labor  inten¬ 
sive  task  due  to  the  amount  of  event  handling  that 
takes  place.  Various  toolkits  have  been  developed 
that  alleviate  the  burden  of  programming  in  Xisb. 
the  most  popular  being  the  X  Toolkit  IntnnsicB 
(Xt).  Applications  using  Xt  are  given  general  fa¬ 
cilities  that  allow  streamlined  event  handling  and 
the  ability  to  create  reusable  display  objects  (like 
windows  or  buttons)  called  widgets. 
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Figure  2:  Architecture  of  X  Window  System  Ap¬ 
plications 


2.3  Widget  Sets 

The  charter  of  X  is  ’‘mechanism  without  policy' 
(6,  8).  Thus,  unlike  some  windowing  systems.  X 
does  not  force  developers  to  ha  ve  a  mandated  style 
to  their  application.  Commercial  widget  sets  such 
as  the  Open  Software  Foundation’s  (OSF)  Motif 
widget  set  fill  in  this  gap.  Layered  on  top  of  Xt. 
this  library  is  used  according  to  a  style  guide,  and 
provides  a  consistent  look  and  feel  across  applica¬ 
tions  written  with  it  [2]. 

3  Ada  Bindings  to  X 

The  X  Window  System  is  written  in  C  without 
consideration  for  language  independence.  This  is 
a  problem  for  programmers  using  Ada  to  develop 
projects.  Language  bindings  to  C  libraries  offer  a 
simple  solution  for  programs  needing  X  function¬ 
ality. 


3.1  Binding  to  C 

In  general,  a  binding  to  C  will  consist  of  four 
parts;  declarations,  preprocessing,  C  calUs),  and 
post-processing.  Figure  3  illustrates  a  typical 
binding.  This  binding  takes  one  parameter  as 
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function  Ada_Cali  (Paran!__One ;  in  Special)  return  Special 
function  C_Call(X:  in  INTEGER)  return  INTEGER; 
pragma  INTERFACE (C,  S_Cali);  ’ 

pragma  INTERFACE  NAME  {C__Ca:i,  •_C_CdiI’'); 

« 

New_Param_Or.e  ;  INTEGER;  / 

Return_Value  :  INTEGER;  t 

begin 

New_Param  ;=  Special_To_INTEGER {Pararr_Cne)  ; 

Return_Value  ;=  C_Cali tNew_Param) ; 
return ( INTEGER_To_Special (Return_Vaiue) ; ; 
end  Ada_Cail;  / 

Figure  3:  An  Example  Ada-lo-C  Binding 
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input,  converts  it  to  an  integer,  and  passes  that 
integer  to  the  corresponding  C  procedure. 

Lines  1—4  declare  the  Ada  binding  function  and 
the  corresponding  C  function.  The  INTERFACE 
statements  let  the  compiler  and  linker  know  that 
a  C  calling  protocol  will  be  needed,  and  the  name 
of  the  function  in  the  C  libraries.  Line  10  illus¬ 
trates  a  simple  preprocessing  segment  of  code. 
The  parameter  ParairuOne  must  be  converted  to 
an  integer  value  before  the  C  call  can  accept  it. 
An  externally  defined  function  accomplishes  this. 
Line  1 1  calls  the  actual  C  function  and  passes  it 
the  converted  value  of  Param-One.  Line  12  post¬ 
processes  the  returned  integer  into  the  desired 
type.  This  is  then  returned  to  the  calling  routine. 

3.2  Binding  Thickness 

Figure  3  is  a  simple  mapping  of  a  C  function  to 
an  Ada  call.  A  more  complex  C  call,  however, 
could  require  much  more  massaging  in  the  pre- 
and  post-processing  areas  to  send  and  return  val¬ 
ues  properly.  The  level  to  which  a  binding  pro¬ 
cesses  information  before  passing  it  on  has  come 
to  be  described  in  terms  of  thickness. 

A  thin  binding  set  is  characterized  by  a  one-to- 
one  mapping  of  Ada  and  C  functions.  Ada  specific 
'eatures  are  only  used  when  a  C-specific  construct 
oay  'sot  be  available.  Within  the  bindings,  min¬ 
imal  amounts  of  processing  arc  apphod  before  or 
after  the  call  to  C. 


Thick  bindings  are  characterized  by  heavy  use 
of  Ada  constructs  and  language  features,  gen¬ 
eralization  of  the  mapping  to  C  tails  (one-io- 
many  mappings),  and  the  addition  of  utility  proce- 
dures/functions.  A  thick  binding  seeks  to  insulate 
the  Ada  programmer  from  the  C  calls  while  giving 
them  the  freedom  to  utilize  Ada  features  to  their 
best  advantage. 

These  become  important  considerations  when 
moving  between  binding  sets.  Moving  from  a 
thick  to  a  thin  binding  will  involve  the  creation 
of  calls  that  were  not  previously  required.  Mov¬ 
ing  from  a  thin  to  thick  binding  may  call  for  a 
redesign  of  some  code  sections  to  make  optimum 
use  of  Ada’s  features. 

3.3  STARS  Binding  Set 

Three  major  sets  of  X  interfaces  are  distributed 
by  the  STARS  Foundation;  Science  Applications 
International  Corp  (SAIC)Xlib  bindings,  Boeing's 
Xt  Intrinsics/OSF  Motif  bindings,  and  the  Unisys 
Ada/Xt  software.  The  Unisys  software  is  an  Ada 
implementation — the  Xlib  and  Xt  Intrinsics  li¬ 
braries  have  been  re-coded  in  Ada. 

The  SAIC  bindings  cover  most  of  the  Xlib  func¬ 
tions,  while  the  Boeing  bindings  cover  some  Xlib, 
a  large  part  of  Xt,  and  most  of  the  OSF  Motif 
functions.  While  carrying  the  characteristics  of 
thin  Llndings,  they  have  some  utility  functions 
and  Ada-specific  constructs.  As  they  were  one  of 
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the  first  sets  of  bindings  available,  many  applica¬ 
tions  used  them  as  an  interface  to  X. 

There  are  problems  with  usihg  these  bindings. 
There  is  little  documentation  available,  so  the 
programmer  usually  must  read  the  source  code 
to  determine  usage.  The  bindings  have  bugs,  and 
users  of  the  bindings  must  correct  them  [1 1.  The 
binding  set  is  not  complete  and  some  bindings 
must  be  created.  The  SAIC  and  Boeing  bindings 
are  not  entirely  compatible,  and  use  of  one  can 
mean  loss  of  some  functionality  in  the  other  {3]. 
Finally,  there  is  no  on-going  support  for  the  bind¬ 
ings  and  they  are  rapidly  becoming  obsolete. 

3.4  Commercial  Binding  Sets 

The  lack  of  support  for  STARS  has  resulted  in 
the  emergence  of  commercially  supported  bind¬ 
ings.  Bindings  such  as  Ada/Motif  by  SERC  are 
based  upon  the  STARS  bindings,  but  have  been 
debugged,  expanded  and  enhanced  to  make  them 
a  viable  product  [7]. 

The  availability  of  these  bindings  makes  it  pos¬ 
sible  for  applications  to  be  upgraded  to  the  latest 
releases  of  the  X  Window  System  and  OSF  Motif. 

4  Converting  Bindings 

With  many  of  the  commercial  bindings  avail¬ 
able  based  on  the  STARS  bindings,  converting  a 
STARS  application  to  a  newer  set  would  seem  a 
simple  task.  Small  applications  do  convert  easily. 
Large  applications,  however,  require  a  careful  ap¬ 
proach  or  excessive  work  will  be  done  for  a  product 
that  is  less  than  optimal.  This  section  discusses 
two  strategies  for  conversion:  low-level  and  high- 
level  mapping. 

4.1  Low-Level  Mapping  Strategy 

Using  the  low-level  style  of  conversion,  the  pro¬ 
grammer  determines  either  all  at  once,  or  incre¬ 
mentally  all  the  STARS  functions,  procedures. 
A!  d  types  in  an  application.  Each  of  these  is  then 
iteratively  converted  to  a  corresponding  func¬ 
tion/procedure/type  in  the  target  binding  set. 


4.1.1  Method 

’  Previous  work  by  Moore  {4]  describes  a  straight¬ 
forward  method  for  converting  each  STARS  iden¬ 
tifier; 

1 .  Find  Base  STARS  Declaration.  Identify  the 
STARS  source  code  statements  that  declared 
the  identifier  This  process  may  need  to  be 
nested,  as  the  goal  is  to  locate  a  standard 
Ada  type  definition. 

2.  Find  Similar  Identifier.  Search  the  target 
binding  specification  for  an  identifier  with 
the  same  or  similar  name  as  the  STARS  iden¬ 
tifier, 

3.  Find  Base  Target  Binding  Declaration.  Iden¬ 
tify  in  the  target  binding  how  this  identifier 
is  declared.  This  process  may  also  need  to  bp 
repeated  to  locate  the  base  Ada  ty^pe  declara¬ 
tion. 

4.  Convert  Between  Base  Declarations.  Using 
the  declarations  from  above,  the  base  type 
of  the  STARS  identifier  is  converted  to  an 
appropriate  type  used  by  the  target  binding 
identifier, 

4.1.2  Example  Conversion 

Saber,  an  air/land  battle  wargame,  was  originally 
coded  using  the  STARS  bindings.  Figure  4  shows 
a  piece  of  the  code  used  to  set  the  colors  of  ter¬ 
rain  features.  In  this  example,  the  code  will  be 
converted  to  the  Ada/Motif  binding  set  using  low- 
level  mapping. 

1.  Find  Base  STARS  Declarations.  The 
only  STARS  identifier  used  in  Figure  4  is 
XT. Pixel  (a  type  identifier).  Looking  in  the 
STARS  declarations  XT. Pixel  is  defined  as 
a  subtype  of  AFS  — hA  j. tlPAi..  Looking  in 
the  boeing-afs  package,  AFS-LARGE_NATURAL 
is  a  subtype  of  AFS-LARGE.INTEGER,  Finally, 
it  is  found  that  AFS,L.M.G£.iN7E'~--  n.  is  defined 
as  an  Ada  INTEGER.  This  is  the  base  Ada 
type  that  is  needed. 
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procedure  Initiali2e_Terr>ein_Colors  {  Poiitical_Red  :  XT. Pixel; 

Political  Blue  :  XT. Pixel; 
Political  Neutral  ;  XT. Pixel; 


City  ;  XT. Pixel  )  is 

begin 

Political_Red_Color  :=  Political_Red; 
Political_Blue_Color  :=  Politicai_Blue; 

Political  Neutral  Color  ;=  Political  Neutral; 


City_Color  :=  City; 

end  Initialize  Terrain  Colors; 


Figure  4;  Section  of  Saber’s  STARS  code 


procedure  Initiali2e_Terrain_Colors {  Political_Red  :  X_Lib. Pixel; 

Politicai_Blue  :  X  Lib. Pixel; 
Political  Neutral  :  X  Lib. Pixel; 


City  :  X_Lib. Pixel  )  is 

begin 

Political_Red_Color  :=  Political_Red; 

Political_Biue_Color  :=  Political_Biue; 

Political  Neutral  Color  :=  Political  Neutral; 


City_Color  :=  City; 

end  Initialize  Terrain  Colors; 


Figure  6:  Low-level  conversion  of  code 
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2.  Find  Similar  Identifier.  There  is  no  Pixel 
in  Ada/Motifs  Xt  Intrinsics  library  package, 
however  there  is  one  in  the*X  library  package. 

3.  Find  Base  Target  Binding  Declaration.  Fol¬ 

lowing  a  procedure  similar  to  that  above.  X. 
Lib. Pixel  will  be  have  a  base  type  of  an  in¬ 
teger  range  (-2  **31  ..  (2  ’*  31)  -  1). 

4.  Convert  Between  Base  Declarations.  Since 
both  Pixels  are  based  upon  integer  values, 
the  conversion  is  simply  to  substitute  the 
new  identifier  for  the  old.  Figure  5  shows 
the  final  product.  Note  that  the  package 
variables  Poiitical-Red.Color,  Poiiticai. 
Blue.Color,  etc.  will  also  require  this  con¬ 
version  in  their  declarations  if  the  assign¬ 
ment  is  to  compile  properly. 

The  converted  code  is  shown  in  Figure  5, 

4.1.3  Advantages 

This  type  of  approach  works  well  with  email  ap¬ 
plications  having  limited  X  functionality.  It  offers 
the  following  advantages: 

•  Little  knowledge  of  X  required.  Since  the 
method  is  somewhat  algorithmic,  a  program¬ 
mer  with  only  a  basic  knowledge  of  X  can  do 
the  simple  comparisons  needed. 

•  No  redesign  required.  In  essence,  this  is  a 
line-by-line  translation  and  avoids  the  need 
for  extensive  redesign  of  the  application  to  fit 
a  new  binding. 

•  Fast  turn-around  times.  Because  it  is  a 
translation  process,  and  because  no  design  is 
required,  the  conversion  can  proceed  rapidly. 

4.1.4  Disadvantages 

While  tempting  to  use,  this  method  fails  on  larger 
applications.  As  Moore  [4]  discovered,  line-by- 
translation  quickly  becomes  unmanageable 
’Tf!  functions  are  introduced  that  interact 
with  each  other.  In  general,  the  disadvantages 
are  categorized  as  follows: 


•  Not  robust.  A  line-by-line  translation  is  only 
effective  if  the  number  of  translations  are 
small,  and  they  match  up  well  with  the  tar¬ 
get  bindings.  For  example,  this  method  fails 
when  8  STARS  target  function  such  as  Xt. 
Se* -Wicae’:  is  encountered  since  there  is  no 
corresponding  Xt  identifier. 

•  No  optimization.  Since  the  STARS  bindings 
were  developed,  X  has  added  new  functions 
that  can  significantly  reduce  the  amount  of 
code  required.  Since  low-level  mapping  does 
not  allow  for  redesign,  these  new  features 
will  not  be  used. 

•  Prone  to  error.  Larger  applications  may  have 
X  values  that  are  global  in  scope  (such  as  de¬ 
fault  drawables);  indiscriminate  conversions 
of  these  values  may  introduce  side-effects.  A 
STARS  binding  may  have  a  base  type  that 
maps  to  a  similar,  but  incorrect  target  bind¬ 
ing  identifier.  For  example,  XT.Arg.L.s:  in 
STARS  appears  to  map  to  Xt .  XtJinc illary. 
Types. Arg.List-?tr  in  SERC  (both  are  ac¬ 
cess  types).  If  this  mapping  is  used,  the 
corresponding  SERC  functions  using  an  ar¬ 
gument  list  wiU  not  compile — they  require 
Xt .Xt  Jincillary.Types .XtJirg.List. 

4,2  High-Level  Mapping  Strategy 

In  larger  applications,  a  more  effective  method  of 
conversion  wrill  be  high-level  mapping.  Using  this 
approach  the  programmer  takes  the  STARS  ap¬ 
plication  and  breaks  it  down  into  sections  of  code 
that  execute  specific  X  tasks.  These  sections  of 
code  are  then  converted  to  the  new  set  of  bind¬ 
ings. 

4.2.1  Method 

1.  Identify  Sections  of  X  Functionality.  Starting 
from  the  X  application  startup  procedures, 
identify  areas  where  specific  tasks  are  being 
accomplished.  For  instance,  an  application 
may  have  a  task  that  creates  a  form.  This 
may  have  subtasks  that  create  pushbutton 
and  label  widgets. 
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2.  Develop  an  Equivalent  Set  of  X  Calls.  For 
each  section  identified,  develop  an  equiva¬ 
lent  set  of  X  calls.  Care  shbuld  be  taken  that 
the  set  of  calls  be  extracted  from  a  version  of 
X  that  the  new  bindings  are  compatible  with. 
The  important  idea  here  is  to  create  the  same 
functionality  for  the  application  using  the 
best  available  X  functions,  procedures,  and 
types.  This  may  require  redesigning  some 
areas  of  the  code. 

3.  Map  Equivalent  Set  to  Thrget  Bindings.  The 
next  task  is  to  map  the  X  calls  to  Ada  bind¬ 
ings.  Commercially  supported  bindings  such 
as  Ada/Motif  generally  have  supporting  doc¬ 
umentation  that  assists  with  this  task. 

4.  Convert  Global  Variables.  Care  must  taken 
that  X  global  values  which  are  used  by  dif¬ 
ferent  sections  of  code  get  converted.  This 
will  tend  to  happen  naturally;  as  sections  of 
code  are  converted,  the  global  variables  will 
become  apparent. 

These  steps  should  be  used  as  guidelines,  and 
not  be  interpreted  as  strict  procedxire.  Conversion 
from  thin  to  thick  bindings,  for  instance,  may  al¬ 
low  a  relaxation  on  the  equivalent  set  of  X  calls 
since  there  may  not  be  a  direct  mapping. 

4.2.2  Example  Conversion 

In  this  example,  another  section  of  Saber  will  be 
converted.  This  piece  of  code,  shown  in  Figvu-e  6, 
creates  a  label  on  the  system’s  startup  form. 

1.  Identify  Sections  of  X Functionality.  The  code 
in  Figure  6  is  a  good  example  of  an  X  task.  It 
creates  a  label  with  a  string  in  it.  There  is  no 
need  for  additional  breakdown  of  the  code. 

2.  Develop  Equivalent  Set  ofX  Calls.  An  equiv¬ 
alent  set  of  X  calls  to  perform  this  function 
are: 

XmStringCreateLtoR {text,  charset ) 
ytSetArg(arg,  resource_name,  value) 
.reateManagedWidget (name, 

widget_class, 

parent, 


args, 

nu.m_arqs) 

XmScringFree (string; 

Note  that  X  provides 

a  function  (XtVaCreateManagedKidget) that 
eliminates  the  need  for  an  argument  list, 
Ada,  however,  cannot  use  this  function  since 
it  has  a  variable  argument  parameter  list. 
The  Ada/Motif  binding  maps  this  function  to 
XtCreaceManaaedKidget  instead. 

3.  Map  Equivalent  Set  to  Target  Bindings.  Each 
function  is  mapped  to  an  equivalent  set  of 
Ada/Motif  bindings.  Note  that  because  Ada 
can  constrain  an  array,  the  num-args  param¬ 
eter  on  XcCreateManagedWidget  is  not  used. 

4.  Convert  Global  Variables.  As  the  mapping 
takes  place,  the  variables  Args  and  Form. 
Widget  will  have  to  be  converted.  Rather 
than  try  a  low-level  mapping  conversion, 
it  is  better  to  determine  what  Xt.Create. 
Managed.Widget  expects  them  to  be.  Change 
them  to  the  appropriate  type,  in  this  case  xt. 
Arg.List  and  Widget  respectively. 

The  results  of  the  conversion  are  shown  in  Fig¬ 
ure  7. 

4.2.3  Advantages 

This  method  works  well  on  applications  of  any 
size,  and  has  several  advantages  over  low-level 
mapping: 

•  Robust.  Since  the  strategy  develops  a  set  of 
X  calls  and  maps  these  to  the  new  bindings, 
it  doesn’t  fail  when  a  non-mappable  STARS 
function  or  identifier  is  found.  In  Figure  6, 
Xt-Set-Widget  will  not  appear  in  the  equiv¬ 
alent  set  or  the  final  code. 

•  Enhanced  performance.  Some  new  func¬ 
tions  in  the  X  Window  System  (such  as 
CreateManagedWidget) take  the  place  of  sev¬ 
eral  older  calls.  Using  these  in  Ada  elimi¬ 
nates  extra  bindings  and  makes  the  code  ex¬ 
ecute  more  efficiently. 
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—  Create  the  TITLE 

Label_Text  XM.Xm_String__Create_L_To_R ( 

"Welcome  to  the  SABER  Post-Processing  System", 
XM.Xm_STRING_DEFAULT_CHARSET  ) ; 
XT.Xt_Make_Arg_List  (  SIZE  =>  3,  ARCS  =>  Args  ) ; 

XT.Xt_Set_Arg{  Args,  XM.XmN_Width,  4000  ); 

XT.Xt_Set_Arg(  Args,  XM.XmN_Unit_Type,  XM.Xm_100CTH_INCHES  ); 
XT.Xt_Set_Arg (  Args,  XM.XinN_Label_String,  Label_Text  ); 
Title_Label  :=  XM.Xm_Create  Label(  Form_Widget,  "Title",  Args  ) 
XT.Xt_Set_Widget {  Child_List,  Title_Label  )  ; 
XT.Xt_Clear_Arg_List (  Args  ); 

XM.Xm_String_Free (  Label_Text  ); 


Figure  6:  Section  of  Saber’s  STARS  code 


—  Create  the  TITLE 

Label_Text  :=  Xm__String_Create_L_To_R  ( 

"Welcome  to  the  SABER  Post-Processing  System" 
Xm_String_Default_Charset  ) ; 

Xt_Set_Arg(  Args(l),  Xm_N_Width,  4000  )  ; 

Xt_Set_Arg(  Args (2),  Xm_N_unit_Type,  Xml000th_lnches  )  ; 
Xt_Set_Arg(  Args (3),  Xm_N_Label_String,  Label_Text  ); 
Title_Label  :=  Xt_Create_Managed_Widget  ("Title", 

Xm_Label_Widget_Class, 

Form_Widget, 

Argsd  ..  3)); 

Xm_String_Free (  Label_Text  ) ; 


Figure  7;  High-level  conversion 


•  Avoids  type  incompatibilities.  One  of  the 
problems  in  low-level  mapping  that  high- 
level  mapping  avoids  is ’^mismatching  ar¬ 
gument  types.  Where  it  was  possible 
to  think  Xt  .Xt_Anciiiary.Types  .Arg.Lasc, 
Ptr  shoiild  be  used  where  XT.Arg.List 
had  appeared  using  low-level  mapping,  it 
wotdd  be  immediately  obvious  that  Xt.Xt. 
Ancillary-Types. Xt-Arg. List  is  used  as  a 
parameter  type  for  all  Ada/Motif  set  argu¬ 
ment  list  functions. 

4.2.4  Disadvantages 

High-level  mapping  is  inherently  more  complex 
than  low-level  mapping.  While  it  handles  many 
cases  that  low-level  can’t,  there  are  tradeoffs; 

•  Requires  expertise  inX.  The  process  for  doing 
this  type  of  conversion  is  not  strictly  defined. 
Programmers  will  need  experience  with  X  to 
identify  functional  areas  and  the  best  set  of 
equivalent  calls  to  use. 

•  Slower  turn-around  times.  Using  the  newer 
features  may  require  design  changes  in  many 
areas  of  the  application.  Changing  the  de¬ 
sign,  creating  equivalent  calls,  and  mapping 
them  to  bindings  will  require  significantly 
more  time  than  line-by-line  translation. 

5  Conclusion 

This  paper  discussed  two  strategies  for  converting 
from  the  STARS  binding  set  to  newer  commercial 
bindings.  Low-level  mapping  is  appropriate  for 
small  applications  with  limited  X  functionality, 
but  does  not  work  well  with  large  applications. 
High-level  mapping  works  well  with  all  applica¬ 
tions  and  produces  cleaner  code,  but  requires  ex¬ 
pertise  with  X  programming. 

The  high-level  mapping  strategy  was  developed 
after  determining  that  Saber  could  not  be  effec¬ 
tively  converted  using  low-level  mapping.  This 
has  proved  to  be  effective,  allowing  us 
c  vert  the  initialization,  main  controller,  and 
game  play  utilities  (about  2000  lines  of  Ada  code) 
in  one  week’s  worth  of  work.  It  was  found  that 


certain  X  tasks  are  repeated  often,  and  conversion 
^  techniques  can  duplicated  for  each.  For  example. 
Figure  6,  which  creates  a  label,  is  representative 
of  about  50%  of  all  the  Saber  code.  Companson 
to  other  examples  12.  5.  6.  7}  verifies  that  this  ib 
characteristic  of  most  X  programs 

As  it  tends  to  produce  a  better  product,  our 
recommendation  is  to  use  the  high-level  mapping 
strategy  for  all  but  very  simple  systems 
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